Subject: RFC 1434 and the 6611

From: [email-masked] (Paul Brittain)
Date: Thu, 18 Nov 93 16:49:02 GMT

Roy,

Thankyou for the note you sent to the DLSw SIG earlier this month about
differences between the 6611 and RFC 1434.  It certainly cleared up a number of
loose ends (such as 6611 flow control) that had been left unclear from earlier
notes on the SIG.

However, as useful notes always do, it has triggered a few more queries!

ENTER/EXIT-BUSY
===============

I infer that these messages correspond to an 'XON/XOFF' type of flow control
at the circuit level.  However the local termination of LLC2 in DLSw implies
that even after sending an ENTER_BUSY message, a switch cannot discard any
further frames that are passed to it by the partner switch.  Indeed, as the
ENTER/EXIT-BUSY messages are (presumably) sent in the normal TCP/IP data streams
and not in the 'reverse' flows as has been suggested for flow control mechanisms
in the SIG discussions, such crossover cases are very likely to occur.

Given this, would the 6611 fail if the partner DLSw did not act on the
ENTER/EXIT-BUSY messages?

(As a subsidiary point, this does not seem like a good basis for a long-term
flow control solution.  I realise you were not trying to propose it as such,
but just in case anyone else on the SIG was thinking of doing so, please don't!
On the other hand, if I have over-simplified the mechanism the 6611 uses here
and it would have more long-term use, please let us know).

Unsolicited ICRs
================

This one worried me rather more.  Up till now I had thought that the base RFC
function was sufficiently similar to the 6611 to virtually give compatability
'for free' once the HALT-NO-ACK and ENTER/EXIT-BUSY messages were added and
obvious omissions from the FSMs corrected (such as the final point in your note)
However this requires a more fundamental change to the FSMs and circuit startup
sequence.

This prompts two questions:

-       Did you mean ICR or CUR?  I had expected from previous discussions
        on the SIG to  see a second CUR when the XID with unequal SAP comes in,
        but not for the flow to jump straight to the ICR.

-       If you did mean ICR, is the following flow correct for the case of a
        circuit setup attempt with SSAP=8 and DSAP=4?  Numbers in brackets are
        the SSAP and DSAP or Origin SAP and Target SAP as appropriate.

Origin                  DLSw A             DLSwB                Target
~~~~~~~                 ~~~~~~             ~~~~~                ~~~~~~
TEST(8,0)                CUR(8,8)            TEST(8,0)
------------------------>------------------->-------------------->

TEST RSP(0,8)            ICR(8,8)            TEST RSP(0,8)
<-----------------------<-------------------<---------------------
                        | RA(8,8)
                        -------------------->

XID(8,4)                  ICR(4,8)            New DLC action to activate link?
------------------------>------------------->.........> (+ possibly a new
                                            |         |  intermediate state)
                          RA(4,8)           |<.........
                        <--------------------
                        | XIDFRAME(4,8)       XIDFRAME(8,4)
                        -------------------->-------------------->

        I am particularly concerned that the origin and target DLSw roles are
        reversed for the second circuit, which makes the origin and target SAP
        interpretation unclear with respect to the end station roles.

        If this flow is correct it requires a new DLC action that will
        activate a link station without sending the TEST response that a
        DLC_RESOLVE_R would issue, plus the ability to buffer a XIDFRAME
        until the REACH_ACK is received.

Since these are not trivial changes to the RFC, can you clarify whether I have
interpreted your note correctly so that the SIG can better understand how the
6611 and the RFC differ in this area.

Retry Absorption
================

Reading between the lines of all the 'Notes:' in the RFC, the 6611 appears to
have chosen not to keep a circuit control block of any form between the sending
of a CUR and the receipt of a REACH_ACK.  However this seems to conflict with
earlier statements on the SIG that the origin DLSw is responsible for
absorbing the retries of TEST or Netbios_NQ frames without reissuing the CUR.

Could you clarify whether the 6611 does absorb such retries (the actual
mechanism is not important though).

Data Link ID
============

This point is not directly related to your note but came up while I was
thinking through the implications of the previous point.

During Netbios circuit setup, does the 6611 ever correlate a Netbios Name Query
and its response using the Netbios names in these messages or does it do all
correlation using the Data Link ID (i.e. there is no real attempt to correlate
the two as they have different Mac addresses)?

The purpose behind this question is to identify a potential semantic difference
between implementations that attempt some form of correlation of circuits
based on Netbios Names rather than MAC/SAP pairs.  It seems fine for an
implementation to retain the RIF data associated with a Netbios Name Query
until the response is returned, but it should not consider this to be a circuit
awaiting resolution.

----------------------

Thank you

Paul Brittain.
Data Connection Ltd
+44 244 313440